In the loop building rawYAML, you’re concatenating the $ command result object directly into a string. In zx this will not reliably produce the command stdout (often becomes "[object Object]"), which will break YAML.parse. Use the command output explicitly (e.g., .stdout or .text()) when appending tag contents.

gh api ... --jq '...{...}' | head -n 1 is brittle because --jq output for objects is typically multi-line JSON; head -n 1 can truncate it (e.g., just "{") and make JSON.parse(prData) fail. Prefer making the jq output single-line (compact) or extracting a single JSON-encoded line before piping to head, so the parsed string is always valid JSON.

allUsers can contain duplicates (e.g., author is also an assignee), and the current filter doesn’t dedupe. That will incorrectly increase users.length, reduce per-person reward, and may create multiple entries for the same payee. Consider normalizing to unique logins (e.g., via a Set) before calculating the split.

The workflow decides whether to run stats based on “new commits since last statistic tag”, but reward tags can be created without any new commits (the claim workflow only pushes tags). In that case this workflow will skip even though there is new reward data. Consider checking for new reward-* tags (or tag dates) instead of commit history, or always run the stats script and let it exit gracefully when there’s no data.

This workflow runs on pull_request events but the “Send message to Lark” step depends on secrets.LARK_CHATBOT_HOOK_URL, which is not available for PRs from forks; the action may fail or behave unexpectedly. Add a guard to skip the job/step when secrets aren’t available (e.g., only run for non-fork PRs) or adjust the trigger strategy (with appropriate security precautions).

For push events, head_commit.url in the webhook payload is an API URL (not a browser-friendly HTML URL), so the generated “提交链接” may point to the REST endpoint. Consider building the commit page link from server_url, repository, and the commit SHA instead (or otherwise ensure the URL is a web URL).

This deno.json lives under .github/scripts/, but the workflows run deno ... .github/scripts/*.ts from the repo root. Deno only auto-loads config from the current directory (and ancestors), so this config likely won’t be applied unless you pass --config .github/scripts/deno.json or move the config to the repository root.

The serialization step runs deno run -A, which grants full permissions (run, env, net, read/write) even though this script appears to only transform stdin to stdout. Tightening permissions here (remove -A and only grant what’s required) reduces blast radius if the script or its dependencies ever become compromised.